3.3 User Interface 4 Related Work

Work on program concept recognition 16, 17, 18] has also innuenced our approach, mainly as regards viewing the sections of code implementing architectural features as clich es. However, our approach differs from the usual one adopted in standard clich e matching. In fact, not all of our recognizers are driven by statement level clich es but some exploit other information , at higher levels of a programming language, such as the calling hierarchy of a module or the use relations among modules. Also when our recognizers try to match some special source code patterns, they do not translate the code under analysis into a more abstract representation, such as, for example the Plan Calculus 16]: on the contrary, they search evidence of the pattern directly in the AST, allowing partial matches. The RIGI environment 3] addresses some of the issues we are interested in, mainly as regards its structural analysis and re-documentation capabilities, and also its powerful, customizable user interface. However , while RIGI is certainly good at dealing with very large scale software, the kind of architectural components and connectors it handles are concentrated on standard imperative language constructs (such as subprogram calls), hence the resulting analyses deal mainly with identiication of subsystems of interest within calling hierarchies. We think that distributed systems are becoming more and more important thus the identiication of inter-process communication con-nectors is as important as the analysis of the internal structure of a program. The works that most heavily innuenced our approach in program architecture understanding and reverse engineering are the already cited works by Har-ris, Reubenstein and Yeh 4, 6]. The philosophy of both their and our approach is substantially the same: we are both interested in discovering architectural commitments in source code for the purpose of program understanding and re-documenting and we agree on the fact that this must be an incremental process. We both placed in the same programming environment , C/Unix, and work on the same representation of source code, ASTs, and with the same tools, Reene and Reene/C. However, rst of all we diier in the conceptual organization of the architectural model. While Harris et al. require some sort of indexing to organize their architectural recognizers library, we use a hierarchical architectural model to help driving the selection and applicability of each recognizer. The result is that our approach may be less demanding with respect to the user, but …